デジタルスレッドによる製造業のデータ統合と生成AI活用のAWSワークショップ

最近、製造業の文脈で、デジタルスレッドという言葉を聞く機会が増えました。

デジタルスレッドとは、製品の設計から製造、販売、アフターサービス、そして最終的な廃棄に至るまでの全プロセスにおいて、デジタルデータが追跡可能な形で糸のようにつながっている状態を表します1。これにより、製品のライフサイクル全体を通じて、データのコンテキスト（文脈）を維持しながら、情報を統合的に管理することが可能になります。
デジタルスレッド - Wikipedia

要は「製造業におけるデータ活用を企業の全プロセスに広げてやってしまおうぜ！」という壮大な試みです。

re:Invent 2024において、このデジタルスレッドをAWSの各種サービスを駆使し、自然言語で問い合わせすると結果が返ってくるチャットボットを作成するワークショップに出席してきました。

Amazon Neptune, Amazon Bedrock, Streamlitなど、生成AI関連で頻繁に名前を聞くサービスが目白押しの面白いワークショップで、さらにワークショップのコンテンツは既にパブリック公開されているため、気になる人はだれでも試すことができるので、この記事を読んで気になった方は、是非実際に手を動かしてみることをおすすめします。

もちろんソースコードも公開されているので、実装がどうなっているのか全て把握できますYO。

ほな、いってみよ！

ワークショップ内容について

ワークショップタイトル：Building a generative AI-based manufacturing digital thread

セッションIDは、MFG302。

Manufacturers have vast amounts of knowledge dispersed across the product lifecycle, often resulting in limited visibility, significant knowledge gaps, and the inability to continuously improve. A digital thread offers an integrated approach to combine disparate data sources across enterprise systems to drive traceability, accessibility, collaboration, and agility. In this workshop, learn how to create an intelligent manufacturing digital thread using a combination of knowledge graph and generative AI technologies based on the data generated throughout the product lifecycle. Explore several use cases and discover actionable steps to kick-start your intelligent digital thread journey. You must bring your laptop to participate.

DeepLによる機械翻訳

メーカーは、製品ライフサイクル全体に膨大な知識が分散しているため、可視性が限定的になり、知識のギャップが大きくなり、継続的な改善ができないという結果になることがよくあります。デジタルスレッドは、企業システム全体に散在するさまざまなデータソースを統合し、トレーサビリティ、アクセス性、コラボレーション、俊敏性を推進する統合的なアプローチを提供します。このワークショップでは、製品ライフサイクル全体で生成されたデータに基づく、知識グラフと生成型AI技術の組み合わせを使用して、インテリジェントな製造デジタルスレッドを作成する方法を学びます。いくつかのユースケースを検討し、インテリジェントなデジタルスレッドの旅を始めるための実行可能なステップを発見します。参加するには、ノートパソコンをご持参ください。

ワークショップ講師

• Raga GT, WW Senior Solutions Architect, Manufacturing, Amazon Web Services
• Vedanth Srinivasan, Head of Solutions, Engineering & Design, Amazon Web Services

ワークショップの主要なトピック

ワークショップの目的は、デジタルスレッドの実装方法を学ぶことです。最初に、講師の方から以下の説明があり、その後に実際にワークショップの環境にアクセスし実装するという内容でした。

1. ビジネス課題の理解

• データサイロ化による非効率性
• 市場投入時間の短縮ニーズ
• 競争優位性の確保
• 品質管理の課題
• コスト最適化

2. デジタルスレッドによるソリューション

• エンタープライズデータの接続
• トレーサビリティの確立
• アジャイルな対応能力
• 部門間コラボレーション

3. 技術アーキテクチャ

• Amazon S3によるデータ統合
• Amazon Neptuneによるグラフデータベース
• Amazon Bedrockによる生成AI機能
• LangChainによるオーケストレーション
• Streamlitによるアプリケーション開発

4. 実装手順

• インフラストラクチャのセットアップ
• データの取り込みと変換
• グラフデータベースの構築
• 生成AIモデルの統合
• アプリケーションのデプロイ

5. ユースケース

• 設計最適化
• サプライチェーン管理
• 品質管理
• 予測保守
• 顧客体験向上

ワークショップでは、これらの概念を実際に体験できるように、参加者がAWSのサービスを使って環境を構築し、デジタルスレッドの実装を行う形式で進められました。

ワークショップの内容は公開済み

このワークショップの内容は既にパブリックに公開されていて、こちらから誰でもアクセスし実行可能です。気になる方は、是非こちらを参考に実装してみてください！

https://catalog.workshops.aws/mfg-digitalthread-graph-genai/en-US

以降、講師の方の口頭での説明を元に、製造業におけるデジタルスレッドの課題や活用方法についての講義が有りました。非常に興味深い内容だったので、詳細に記載をしています。

また、このワークショップの開催に先立って同名のブログがAWSから公開されていました。こちらにもこのワークショップと同じ内容が解説されています。

https://aws.amazon.com/jp/blogs/industries/building-a-manufacturing-digital-thread-using-graph-and-generative-ai-on-aws/

Introduction

このセッションへようこそ。私はVedashvini Vatsanです。エンジニアリングとデザインのソリューション責任者として、業界横断的なスケーラブルなソリューションの構築に焦点を当てています。

最初の10分ほどで、問題提起について説明します。なぜこの問題を解決する必要があるのか、ビジネスへの影響と全体的な成果は何かについてお話しします。次に、インフラの構築に焦点を当てます。

1. ビジネス課題の理解

それでは始めましょう。まず概要として、顧客の視点から説明させていただきます。私たちは顧客の課題に対応することに注力しています。お客様との対話の中で、よく聞かれる上位5-6個の課題があります。

顧客は常に新しいビジネスの獲得を目指しています。既存のビジネスは順調に進んでいますが、新しい地域の開拓や、新しい技術の導入、あるいは新しい分野への参入を検討されています。新規ビジネスの獲得は常に大きな課題として顧客の心に浮かびます。

2点目は常に市場投入までの時間です。製品を開発し、次世代の製品を作り出していますが、既存のデータを活用して市場投入を早めることはできないでしょうか？何かを削減できないか？何かを加速できないか？そして市場投入の成果をどのように最適に達成するか？

3点目は競争圧力についてです。常に製品があり、顧客は多くの選択肢を持っています。つまり、あなたの製品は差別化される必要があります。エンドユーザーからのフィードバック、顧客からのフィードバックからどのような需要シグナルを得て、競争力のある差別化された製品を構築し、さらなるデバイスを開発していくのでしょうか。

また、品質指標についてもよく耳にします。製品のライフサイクルを見ると、設計時、構築時、製造時、保守時があります。ライフサイクルを通じて、常に品質管理が必要です。なぜなら、ライフサイクルを通じてデータが変化する可能性があるからです。

問題は、設計から展開まで全ライフサイクルを通じて、データの品質、製品の品質をどのように維持するかということです。また、コスト削減についても聞きます。これは利益率の改善かもしれませんし、生産性や個人の成果を見ているのかもしれません。

結果として、既に取り組んでいることをどのように再利用するかということになります。これらの側面すべてにおいて、コンプライアンスを含め、適切な場所で適切なタイミングでデータにアクセスする必要があります。

これらの需要シグナルを分析していく中で、McKinseyによる調査で、顧客のビジネス成果を妨げているデータを活用することで、約1,000億ドルの価値が解放される可能性があることが分かりました。

重要な点は、その20-30%が企業のコラボレーションから生まれるということです。人々はサイロ化され、データは各自のボックスに閉じ込められています。十分なコラボレーションが行われていません。

しかし、ステークホルダー間でコラボレーションを始め、データを活用することができれば、より多くのビジネス成果を解放することができます。しかし、現在の組織の状態はそのように設定されていません。

設計から製造、生産、運用までのライフサイクルを通じて、多くのエンタープライズシステム、CADデータ管理、要件データ管理、PLM、MESシステム、保証トレーニングマニュアルなどの記録システムがあります。これらはすべてExcelシートや他のエンタープライズシステムに設定されています。

その上に、日常的なビジネスは営業、HR、コンプライアンス、その他のビジネス機能と連携して機能する必要があります。

製品を開発している場合、サプライヤーやサードパーティのインテグレーターと頻繁に協力する必要があります。つまり、データはセキュアでなければなりませんが、同時にサードパーティからアクセス可能で、相互運用可能である必要があります。

典型的な問題提起として、これは一般的な説明に過ぎませんが、皆さんにも当てはまるかもしれません。生成AIを使うべき理由は何か？どのようなデータを持っているのか？という観点から、自分のユースケースを構築することができます。

重要な質問は、どのようなビジネス成果を達成しようとしているのか、ということです。ビジネスユースケースがあれば、そこから逆算して、システムにどのような質問をすべきか、どのような答えを求めているのかを考えることができます。

これらは顧客からよく聞く例の一部です。設計部門の誰かが何かのために設計をしています。サプライチェーンのための設計、信頼性のための設計、品質基準などです。しかし、おそらく意思決定に必要な適切なデータを前もって持っていません。

そこで、材料は本当に入手可能なのか、といった質問をします。4年前、チップ不足がありました。チップを想定して製品を設計していた人々は、チップが不足していることに気付きました。設計時にサプライチェーンのことを考えていなかったのです。これは大きなコストの不一致を生みました。

部品の遅延の原因を理解したい場合、何がボトルネックになっているのかを知りたい場合、企業全体やデータにアクセスできる人々に問い合わせる必要があります。生成AIはこれに適したユースケースです。

また、VD（検証・デザイン）担当者が、これまで100回同じ作業をしてきて、101回目をやろうとしている場合があります。なぜすべてを最初からやり直す必要があるのでしょうか？既存のデータを使用し、以前行ったことを照会し、類似性検索を行って、さらに何をすべきか、あるいは既存の作業を補完するだけで良いのかを特定できないでしょうか？

ユースケースは非常に大きく、幅広いものですが、再度申し上げますが、多くの成果を考えることができますが、それは見つけた順序から始まります。

データについて、皆さんはデータにアクセスできますが、それは複数のサイロ、複数のエンタープライズシステムに閉じ込められています。PRMバケット、CRMシステムを見ても、大量のデータが保持されていますが、他のステークホルダーからアクセスできない状態です。

エンドツーエンドで見ると、市場ニーズがあり、製品をリリースしたい、どのようにデータを接続し、インフラストラクチャを解析し、適切なタイミングでデータを接続するかということになります。

顧客から聞く一般的なアプローチは、コネクテッドエンタープライズです。多くの場合、デジタルスレッドという言葉を聞くとき、人々はこのような企業を指しています。つまり、部品や製品、資産を作成するたびに、それには複数の構成、複数のバリエーションがあります。

何百もの異なるバリエーションをリリースでき、ライフサイクルの多くの部分に進むことができます。問題は、追跡できるかということです。誰が、何を、いつ、どこで、どのように行ったかを見つけることができますか？その質問に答えることができれば、オンデマンドで情報を遡って追跡し、適切なタイミングで適切なデータを使用して適切な判断を下すことができます。

これにより、再利用や、おそらく作業を行っているか、以前にはアクセスできなかったデータにアクセスしているような問題が削減されます。今や、双方向の情報の供給があります。企業全体のステークホルダーにフィードバックを提供することもできます。

2. デジタルスレッドによるソリューション

結局のところ、このデジタルスレッドを構築するアプローチを取っているのは、4つの大きな業界の問題を解決したいからです。

1つ目はデータのアクセシビリティです。必要なとき、適切な人々と協力する必要があるときのオンデマンドデータです。

2つ目はトレーサビリティです。企業データ構造全体の接続性を確立し、データを遡って追跡し、オンデマンドでデータを抽出できるようにします。

3つ目はアジリティです。プロセスを定義し、標準作業を持っていますが、上流または下流で何かが変更された場合、プロセスがどれだけ迅速に変更に対応できるかということです。要件が変更されたとき、それがどれだけ速く下流に伝わり、その情報を取り込み、把握できるかということです。

4つ目はコラボレーションです。人的コストと資本集約的な側面について話しました。再利用について、効果的なコラボレーションについて話をすると、小さな資産レベルではなく、システムレベルで最適化が行われるということです。

それでは、なぜこの問題をインフラで解決するのかを見てきましたが、ワークショップに入る前に、このデジタルスレッドインフラの作成についてもう少し詳しく話をしましょう。

3. デジタルスレッドの技術的アーキテクチャ

それでは、今から実行するソリューションアーキテクチャについて少し話しましょう。そこには10の異なるステップがあります。まず第一に、製造業組織における主要なステークホルダーを特定することです。

重要な点は、設計エンジニアリング、製造エンジニア、工場計画担当者、サプライチェーンマネージャー、システムエンジニアリングチームなどの主要なステークホルダーを特定することです。ステークホルダーとそのニーズを特定する必要があります。

技術的な問題ではなく、プロセスの問題として考えてください。なぜなら、すべての組織は異なっており、その問題も完全に異なるからです。技術的な側面に入る前に、まずステークホルダーのニーズとそのプロセスから始める必要があります。

次のステップはデータソースの特定です。製造組織には、製品ライフサイクル管理システム、ERPシステム、MESシステム、あるいは独自のエンタープライズシステムがあるかもしれません。

これらのシステムを特定し、そのステークホルダーのニーズに関連するデータを特定する必要があります。グラフにすべてのデータをダンプする必要はありません。組織の観点から必要なものを特定し、これらのシステムからデータを抽出するだけです。

これを行うには多くの方法があります。Amazon Database、AWS Database Migration Service、AWS Data SyncなどのAWSサービスを使用して、データをAmazon S3にプッシュすることができます。このワークショップでは、すでにすべてのデータがCSVファイルとしてAmazon S3にあるので、これらすべての作業を行う必要はありません。

理想的には、これらのシステムへのコネクタを実際に作成したいと考えています。例えば、SAPコネクタが準備できている場合、SAPへのコネクタを構築し、自動的にデータを抽出してS3に入れたいと考えています。

2番目は、PLMシステム、例えばVintio、Siemens、Desosなどのシステムからの情報を自動的に抽出してS3に入れる必要があります。私たちはそれらのコネクタを構築しています。多くの顧客と話をしていて、その質問をよく受けるからです。

どのようにデータを抽出してS3に入れるのか？これらの質問に答える必要があります。そのため、私たちはそれらのコネクタを構築しています。

3番目は、S3にデータがある場合、グラフデータベースであるAmazon Neptuneにそのデータをネプチューンローダーを使用してロードできます。バルクローダー機能があります。CSVファイルをAmazon Neptuneにロードできます。これにより自動的にエッジとバーテックス（ノードと関係性）が作成され、グラフが生成されます。

次は、Amazon Bedrockです。Amazon Bedrockは生成AIサービスで、おそらくほとんどの方がご存知だと思います。Amazon Bedrockには、多くのサードパーティモデルがあります。しかし、このワークショップでは、Claude 3.5を使用します。ワークショップを行う際は、必ずClaude 3.5モデルを選択してください。

そして、オーケストレーション層があります。グラフと生成AIの間の接続をオーケストレーションするためにLangChainを使用しています。

最後に、アプリケーション層があります。Streamlitを使用してアプリケーション層を作成し、それをコンテナ化してECSに配置しています。これは完全にAmazon Cognitoを使用して認証されています。

Copilot CLIを使用してアプリケーションを構築し、クラスターにデプロイします。最後に、セキュリティと管理ガバナンスについて、このアプリケーション以外でのWAFの使用方法について、後ほどワークショップが完了したら少しお話しします。

4. ワークショップの実装手順

ワークショップ全体が自動化されています。基本的にインフラの構築は30分間で実行され、VPCを作成し、2つのクラスターを作成し、ユーザーIDを作成し、ユーザーアプリケーションも作成します。ほとんどすべてが自動化されており、ボタンを1回クリックするだけで作成できます。

その間、ユースケースについて少しお話ししましょう。ワークショップに入る前に、3つの主要な構成要素があります。グラフ、オーケストレーション層、生成AIです。

ここで示す図のように、ユーザー、品質エンジニア、工場管理者が質問をしています。部品に問題があり、要件や関連部品を知る必要がある、といった質問です。

現在、彼らは製造エンジニアと話をし、エンジニアリングチーム、設計エンジニアリングチーム、サプライヤーと話をしています。多くの会話に時間がかかっています。

しかし、これらのデータをすべて接続すると、あちこち行く代わりに、自然言語で質問をして回答を得ることができます。最初に質問をすると、それは大規模言語モデルに送られ、オープンサイファークエリ（グラフクエリ）が生成されます。

これは、アプリケーションで提供する情報に基づいて自動的に生成されるグラフクエリです。グラフクエリはナレッジグラフに送り返され、ナレッジグラフから情報を抽出します。

出力はJSONドキュメントとなり、このJSONファイルは再び大規模言語モデルに送られ、より自然な言語でユーザーに送り返されます。基本的にユーザーはデータがどのように構造化されているかを気にする必要はなく、質問をして自然言語で回答を得るだけです。

英語でも日本語でも関係なく、データに関係なく回答を得ることができます。それでは、ワークショップに入りましょう。

ワークショップの進行中にでてきた内容

ここまでワークショップとしては長い前説があったのですが、ワークショップの中のドキュメントでもいくらか紹介したいものがあったので、ここに記します。

改めての全体感とアーキテクチャについて

ワークショップの前段で講師の方から説明がありましたが、改めて冒頭デジタルスレッドについての外観が図示されています。これ1枚で、デジタルスレッドが何なのかが喋れてしまう気がするオススメの図です。

さらに、なぜグラフDBと生成AIを利用するのかの解説。

グラフでは、製品データや要件がエンティティノードとして表現され、エッジがそれらの意味的なつながりを表現します。この構造により、関連データをシームレスにナビゲート可能となります。

このようにナレッジグラフはデジタルスレッドのユースケースには最適ですが、グラフクエリを自然言語から自動生成するには課題があるため、そのUXを向上させるためにLLMを利用してグラフデータを解釈し、関係性を分析しクエリを生成する必要があります。

ワークショップ中のアーキテクチャ。AWSサービス以外だと、OrachastrationのところにLangChain、FrontEndにStreamlitがあります。

実際にできあがったアプリケーションの様子

一通り設定が完了すると、このようなチャットボット画面が表示されます。

いくらか、質問と回答内容を紹介します。自然言語による問い合わせが、グラフDBへのクエリに変換されていることもわかります。

質問1

品質不良 QC-1234-1 について教えてください。影響を受けた部分と技術的要件についても知りたいです。

生成されたクエリ

MATCH (qd:QualityDefect {name: 'QC-1234-1'})<-[:quality_defect]-(op:Operation)<-[:operation]-(po:ProductionOrder)<-[:production_order]-(p:Part)-[:allocation_by_requirements]->(r:Requirement) RETURN  [qd.name](http://qd.name/) AS defect_name, qd.description AS defect_description, qd.testresult AS test_result, [p.name](http://p.name/) AS part_name, [r.name](http://r.name/) AS requirement_name, r.description AS requirement_description

回答

もちろんです！品質不良 QC-1234-1、影響を受ける部品、関連する技術的要件について、喜んで情報をご提供いたします。

品質不良 QC-1234-1 は特定の部品の回転数（rpm）に関連しています。テスト結果によると、回転数は10,000であるべきですが、実際には9,800で計測され、テストに不合格となりました。

影響を受けた部品は、Turbo-Motor-11234です。これは、性能、安全性、規制基準など、いくつかの技術的要件を満たすように設計されたターボモーターです。

この欠陥に直接関係する特定の技術的要件は、技術的要件2（Technical-Requirement-2）で、「ターボモーターの回転数は10000rpmでなければならない」と規定されています。測定された回転数（9,800）がこの要件を満たしていないため、テストが不合格となった理由が説明されます。

この欠陥は、馬力やトルク出力（技術的要件1）といった他の要件にも影響を及ぼす可能性があることに注目すべきである。ただし、低回転がこれらの側面にどのような影響を及ぼすかについての具体的な情報は得られていない。

この品質問題に対処しなければ、ターボモーター11234が設計仕様を満たし、さまざまな車両アプリケーションで意図した通りに動作することは保証されない。

質問2

部品「Turbo-Motor-11234」のサプライヤーは誰ですか？

生成されたクエリ

MATCH (p:Part {name: 'Turbo-Motor-11234'})-[:supplied_by]-(s:Supplier) RETURN [s.name](http://s.name/) AS supplier_name

回答

提供された情報に基づき、部品「Turbo-Motor-11234」のサプライヤーは以下の通りです。

1. Max Holdings
2. Edge Supplier
3. NFI International
4. TXP Manufacturing

この4社が指定された部品のサプライヤーとしてリストアップされています。これらのサプライヤーはそれぞれ、Turbo-Motor-11234またはそれに関連する部品を提供している可能性が高いです。各サプライヤーの提供品目や、それらがこの特定の部品とどのように関連しているかについて、より詳細な情報が必要な場合は、これらのサプライヤーに直接連絡するか、Turbo-Motor-11234に関する追加の資料を参照してください。

質問3

1. Turbo-Motor-11234 部品の LCA、PCF、Scope3 排出量データを提供できますか？

生成されたクエリ

MATCH (p:Part {name: 'Turbo-Motor-11234'})-[:sustainabilitykpi]->(s:Sustainability) RETURN s.lca, s.pcf, s.scope3emissions

回答

もちろんです。Turbo-Motor-11234部品のLCA、PCF、およびScope 3排出量データをお送りいたします。入手可能な情報に基づくと、

Turbo-Motor-11234のライフサイクルアセスメント（LCA）はモーター1個あたり1800kgのCO2相当量です。この値は、生産から廃棄までのモーターのライフサイクル全体における環境への影響の合計を表しています。

ターボモーター11234の製品カーボンフットプリント（PCF）は、エネルギー出力1単位あたり0.25kgのCO2換算値です。この数値は、モーターの稼働中に排出される温室効果ガスの量を、エネルギー出力との相対値で示しています。

ターボモーター11234のスコープ3排出量は、モーター1台あたり1200kgのCO2換算値です。これらの排出量は、同社の直接的な業務やエネルギー使用以外の、モーターのバリューチェーンで発生する間接的な温室効果ガス排出量を表しています。

これらの数値は、ターボモーター11234の生産、稼働、および関連サプライチェーンの排出量を網羅し、環境への影響を総合的に示しています。

まとめ：デジタルスレッドという壮大な概念を、実際のAWSサービスで構築することが実感できる貴重なワークショップ

自分正直このワークショップに申し込むまでデジタルスレッドのことを聞いたことがなかったのですが、実際にこのワークショップを受けてみて、デジタルスレッドが何なのか、その実現手段がグラフDBと生成AIがキーになっている理由、実際のアーキテクチャなどを体験することができて非常に有意義で楽しいワークショップでした。

re:Invent 2024ではワークショップも数多く開催されていて自分も多数参加したのですが、事前の解説含めて個人的な満足度はかなり高かったです。

ワークショップは、開催後そのコンテンツへのアクセスが時限式になっているものも多いんですが、このワークショップのコンテンツはパブリック公開されていて、内容を詳細に把握することが可能です。

まだ、LangChainやAmazon NeptuneやAmazon Bedrockへの理解が薄い自分ですが、実際のユースケースにそった題材がネタになっているので、このワークショップをネタにこれら技術について手を動かしながら学んでいきたいと思ってます。デジタルスレッドに興味がある方は、是非一緒に手を動かしてみましょう！

それでは今日はこのへんで。濱田孝治（ハマコー）でした。